Interface-driven Model-based Test Automation

M odel-based test automation has helped reduce cost, provide early identification of requirements defects, and improve test coverage [1, 2, 3, 4, 5, 6]. Industry use of model-based test automation has provided insight into practical methods that use interface driven analysis with requirements mod-eling to support automated test generation. However, the term interface is used loosely in this article. An interface is a component's inputs and outputs, along with the mechanism to set inputs, including state and history information , and retrieve the resulting outputs. Recommendations are provided to perform the modeling of textual requirements in conjunction with interface analysis to support reuse of models and their associated test driver mappings. Test-driver mappings specify the relationships between model variables and the interfaces of the system under test. The insights are useful for understanding how to scale models and the associated test-driver map-pings to support industry-sized verification projects, while supporting organizational integration that helps leverage key resources. We have applied the model-based test-automation method called the Test Automation Framework (TAF) since 1996. TAF integrates various government and commercially available model-development and test-generation tools to support defect prevention and automated testing of systems and software. TAF supports modeling methods that focus on representing requirements such as the Software Cost Reduction (SCR) method as well as methods that focus on representing design information such as Unified Modeling Language (UML)-based tools or Mathwork's Simulink, which supports control system modeling for automotive and aircraft systems. With model translation, requirements-based or design-based models are converted into test specifications. T-VEC is the test generation component of TAF that uses the test specification to produce tests. T-VEC supports test-vector generation, test-driver generation, requirements test-coverage analysis, and test results checking and reporting. Test vectors include inputs as well as the expected outputs with requirement-to-test traceability information. The test-driver mappings and the test vectors are inputs to the test-driver generator that produces test drivers. The test drivers are then executed against the implemented system during test execution. There are papers that describe requirements modeling [7] and others with examples that support automated test generation [3, 8, 9, 10]. Aissi provides a historical perspective on test-vector generation and describes some of the leading commercial tools [11]. Pretschner and Lotzbeyer briefly discuss extreme modeling that includes model-based test generation [12], which is similar to uses of TAF. There are various approaches to model-based testing and Robinson hosts a Web site that provides …